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Introduction 

Recently  in  the  INCOSE  Insight,  Fellow’s  Edition,  Jeffrey  O.  Grady  [1]  discussed  Robert  E. 
Machol’s  1965  concept  of  the  “T-Shaped”  domain  knowledge  of  the  systems  engineer.  He 
challenged  that  in  reality,  most  systems  engineers  are  somewhat  broader  in  knowledge  than  just 
their  core  discipline.  In  effect,  there  is  a  movement  to  become  “domain”  systems  engineers  with 
general  knowledge  of  the  various  technical  specialties  that  contribute  to  that  field.  While  much 
has  been  written  on  requirements  analysis,  subtle  variations  in  describing  a  problem  can  still 
have  major  impacts  on  the  potential  solutions  being  sought  or  the  usefulness  of  the  solution 
selected.  Underestimating  the  value  of  operational  domain  knowledge,  or  not  being  able  to 
effectively  convey  the  knowledge  can  lead  a  project  towards  a  poor  or  suboptimal  solution. 

This  gives  rise  to  the  concept  of  operational  domain  systems  engineering  knowledge. 

Operational  Domain  Systems  Engineering  Knowledge 

A  slight  refinement  beyond  technical  or  engineering  domain  knowledge  is  proposed,  which 
includes  operational  knowledge  and  experience.  This  can  be  labeled  operational  domain  systems 
engineering.  The  ability  to  accurately  comprehend  and  express  the  important  factors  within  a 
problem  space  as  well  as  to  accurately  judge  potential  usefulness  absolutely  relies  on  such 
operational  understanding  and  experience.  This  is  quite  different  from  design  knowledge.  For 
example,  few  aeronautical  engineers  have  actually  piloted  the  final  produced  aircraft.  Systems 
are  created  for  use  and  those  that  are  involved  in  the  day  to  day  engineering  design  trade 
decisions  rarely  use  or  maintain  the  systems  they  develop. 
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Figure  1:  Knowledge  Spaces  [1] 


Submitted  to  INCOSE  Insight,  June  2006 


1 


Report  Documentation  Page 

Form  Approved 

OMB  No.  0704-0188 

Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 

VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  OMB  control  number. 

1.  REPORT  DATE 

JUN  2006  2.  REPORT  TYPE 

3.  DATES  COVERED 

00-00-2006  to  00-00-2006 

4.  TITLE  AND  SUBTITLE 

Operational  Domain  Systems  Engineering 

5a.  CONTRACT  NUMBER 

5b.  GRANT  NUMBER 

5c.  PROGRAM  ELEMENT  NUMBER 

6.  AUTHOR(S) 

5d.  PROJECT  NUMBER 

5e.  TASK  NUMBER 

5f.  WORK  UNIT  NUMBER 

7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

Air  Force  Institute  of  Technology, Air  Force  Center  for  Systems 
Engineering, 2950  Hobson  Way, Wright  Patterson  AFB, OH, 45433 

8.  PERFORMING  ORGANIZATION 

REPORT  NUMBER 

9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

10.  SPONSOR/MONITOR'S  ACRONYM(S) 

11.  SPONSOR/MONITOR'S  REPORT 
NUMBER(S) 

12.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  unlimited 

13.  SUPPLEMENTARY  NOTES 

14.  ABSTRACT 

15.  SUBJECT  TERMS 

16.  SECURITY  CLASSIFICATION  OF:  17.  LIMITATION  OF 

_ _ _  ABSTRACT 

18.  NUMBER  19a.  NAME  OF 

OF  PAGES  RESPONSIBLE  PERSON 

a.  REPORT  b.  ABSTRACT  c.  THIS  PAGE  Same  OS 

unclassified  unclassified  unclassified  Report  (SAR) 

4 

Standard  Form  298  (Rev.  8-98) 

Prescribed  by  ANSI  Std  Z39-18 


Region  of  Effective  Communication 

The  relationship  between  users,  systems  engineers,  and  sub-system  design  engineers  is  the 
foundation  for  developing  a  useful  system.  Not  only  must  the  three  parties  cooperate  in  order 
to  effectively  translate  requirements  to  specifications,  they  must  continue  to  interact  during  the 
trades  made  throughout  detailed  sub-system  design  and  integration.  The  Region  of  Effective 
Communication  (REC),  shown  in  Figure  2  represents  the  ability  of  team  members  from  each 
perspective  to  communicate  and  evaluate  choices  to  make  optimum  system  level  decisions.  A 
lack  of  constructive  interaction  between  the  three  parties  can  lead  to  an  ineffective  system 
solution.  As  each  of  the  three  groups  gains  a  better  understanding  of  the  other  two,  the 
interaction  becomes  more  effective,  moving  into  the  Region  of  Effective  Communication. 
Systems  engineers,  having  typically  developed  out  of  a  technical  engineering  field  (aeronautical, 
mechanical,  electrical,  software,  etc.),  are  well  suited  to  communicate  with  sub-system  design 
engineers  during  a  development  project.  The  communication  between  engineers  and  users  is 
often  more  difficult.  One  way  to  improve  the  interaction  between  these  parties  is  to  employ 
systems  engineers  with  experience  in  the  operational  community  -  operational  domain  systems 
engineers. 
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Figure  2.  Region  of  Effective  Communication  (REC) 


Historical  Case  Study 

Executed  during  the  late  1970’s,  The  Pave  Low  III  program  involved  the  modification  of  an 
Air  Force  combat  rescue  helicopter  intended  to  rescue  downed  pilots  during  Vietnam. 
Technology  was  required  to  overcome  the  operational  challenges  presented  by  night  operations 
before  the  introduction  of  the  night  vision  devices  now  common  among  military  aviators.  The 
problem  space  involved  requirements  to  successfully  navigate,  avoid  terrain,  visually  locate 
downed  pilots  and  maintain  aircraft  control  without  outside  visual  references.  At  that  time,  any 
solution  had  to  include  multiple  components  that  addressed  parts  of  the  problem  as  well  as 
provide  integrated  system  level  performance  for  the  overall  mission  task.  The  program  had 
failed  twice  previously  as  it  wrestled  with  cost  versus  benefit  in  developing  a  useful  solution  to 
the  problem.  During  the  third  attempt,  the  development  organization  (System  Program  Office) 
recognized  the  need  for  an  experienced  operator  (pilot)  with  an  engineering  background  to 
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participate  in  the  development.  By  developing  and  prioritizing  requirements,  interacting  with  the 
technical  engineering  team  during  the  design,  and  planning  for  test  and  evaluation,  this  operator, 
Lt  Col  Frank  Pehr,  fulfilled  several  critical  systems  engineering  functions.  In  the  words  of  the 
Chief  Engineer  [2],  “His  efforts,  probably  more  than  any  other  individual’s,  made  the  [Pave  Low 
III]  operationally  successful.  He  recognized  both  [user]  needs  and  the  [acquisition  engineering] 
problems”.  Lt  Col  Pehr  effectively  bridged  the  gap  between  the  user  community  and  the 
technical  engineers  and  maintained  a  focus  on  end  usefulness  for  the  entire  team  throughout  the 
development. 

Recent  Observations 

In  the  early  stage  of  the  system  lifecycle,  the  role  of  the  operational  domain  systems 
engineering  appears  most  useful.  Observations  during  several  sponsored  projects  confirm 
extremely  effective  application  of  the  early  Systems  Engineering  process,  when  military 
operators  (predominantly  pilots)  are  trained  in  Systems  Engineering  and  given  large  complex, 
military-related  problems. 

During  one  project,  we  supported  a  project  to  reduce  helicopter  mishaps  in  dusty 
environments  such  as  Afghanistan  and  Iraq.  These  aircraft  are  susceptible  to  re-circulating  dust 
in  arid  desert  regions  that  reduce  visibility  and  significantly  increasing  the  risk  of  aircraft  mishap 
during  low  altitude  hover,  landing  and  takeoff;  this  is  called  “brownout”.  Numerous  sensors 
were  evaluated  to  determine  their  applicability  to  seeing  through  brownout.  Initially,  many 
sensor  engineers/  technologists  assumed  the  ability  to  detect  objects  through  the  dust  equated  to  a 
successful  system  solution.  For  example,  technologies  such  as  millimeter  wave  radar  show 
promise  in  penetrating  visual  obscurants,  but  lack  the  resolution  required  to  make  good  decisions 
during  landing.  Due  to  the  efforts  of  the  operational  domain  systems  engineers,  they  were  able 
to  convey  to  the  entire  team  that  the  integrated  solution  hinged  on  the  ability  to  maintain  aircraft 
control,  more  than  merely  detecting  objects  through  a  dust  cloud.  Maintaining  situational 
awareness  of  the  hazards  surrounding  the  aircraft  is  important  and  could  be  aided  by  sensor 
information,  but  is  a  secondary  consideration  to  safely  control  the  aircraft. 

Other  recent  examples  include  the  development  of  Special  Operations  Forces  Air 
(SOFAir)  Mission  Planning  Enterprise  architecture,  when  designed  by  a  Systems  Engineering 
team  including  a  SOF  helicopter  pilot.  Another  group  of  four  F-15E  “Strike  Eagle”  pilots 
performed  concept  refinement,  simulation  and  analysis  for  improved  time  sensitive  targeting, 
using  Weapon-home  Battle  Damage  Assessment  techniques.  Lastly,  two  F-15C  pilots  provided 
a  strong  systems  engineering  team  in  optimizing  capability  by  selecting  various  modifications  for 
the  extended  life  of  the  F-15C  fleet.  While  these  examples  have  been  defense-related,  it  is 
envisioned  that  operational  domain  knowledge  would  be  beneficial  in  early  commercial 
lifecycles  also. 

Conclusion 

The  chasm  separating  the  developers  of  a  new  system  and  the  operators  who  will  employ 
it,  often  leads  to  reduced  overall  system  effectiveness  (even  though  the  system  may  meet  all 
designated  system  perfonnance  specifications).  Perhaps  the  best  way  to  ensure  end  “usefulness” 
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during  the  development  of  a  new  system  is  to  employ  systems  engineers  with  actual  operational 
experience  (both  using  and  maintaining  related  systems)  in  the  problem  domain.  To  the  extent 
that  the  system  engineer  can  possess  operational  knowledge,  this  would  certainly  amplify  their 
utility  in  the  early  development  work  [3].  This  concept  is  termed  operational  domain  systems 
engineering  knowledge,  refining  Jeffrey  O.  Grady’s  Systems  Engineering  knowledge  concept 

Ill- 


References 

1.  Jeffrey  O.  Grady,  “The  Ultimate  Foundation  of  Systems  Engineering”.  INCOSE 
INSIGHT:  Fellows  Edition,  Vol  8,  Issue  2,  March  2006. 

2.  Leo  Gambone,  “Pave  Low  III,  That  Others  May  Live”.  USAF  Aeronautical  Systems 
Division  History  Office,  pg  68-69,  April  1988. 

3.  Jeffrey  Grady,  personal  communication,  May  2006. 


Submitted  to  INCOSE  Insight,  June  2006 


4 


